На сайте проекта VMware Labs очередное обновление: вышло интересное средство для мониторинга кластеров VMware vSAN - мобильная утилита vSAN Live. С помощью данного приложения для iOS (9.0+) или Android (4.1+) можно организовать мониторинг инфраструктуры отказоустойчивых хранилищ vSAN, находясь за пределами инфраструктуры компании (например, в отпуске или командировке).

Полный список возможностей утилиты vSAN Live:

• Дэшборд с обзором всех кластеров vSAN.
• Полный набор выполняемых для vSAN хэлс чеков.
• Просмотр структуры кластера, включая Fault domain и статусы хостов.
• Простое переключение между серверами vCenter.
• Просмотр конфигурации кластера, включая настройки vSAN и статус сервиса.
• Полнофункциональный мониторинг производительности для виртуальных машин и кластера в целом, а также мониторинг емкости хранилищ кластера.

Самое полезное - это возможность выполнять health checks, что даст возможность понять, что и где сломалось в кластере vSAN:

Скачать приложение vSAN Live можно по этим ссылкам:

Для начала работы с приложением нужно скачать сертификат, расположенный на сервере vCenter по адресу:

https://<VC_FQDN>/afd/vecs/ca

Для установки сертификата на iOS:

• Идем в Settings -> General -> Profiles -> CA -> Install
• Далее: Settings -> About -> Certificate Trust Settings -> CA (enable)
  

Для установки сертификата на Android:

• Открываем сертификат -> Даем ему имя -> Ставим "Credential Use: VPN and apps" -> жмем OK

Пока это всего лишь первая версия утилиты, в дальнейшем, будем надеяться, там появится еще больше интересных функций.

В рамках прошедшей конференции VMworld Europe 2019 было сделано не так много анонсов, как на главной конференции года VMworld 2019. Между тем, кое-что новое там все-таки было анонсировано. Например, было объявлено о выходе новой версии продукта vRealize Log Insight Content Pack for vSAN 2.2. Напомним, что о версии данного контент-пака 2.1 мы писали в январе этого года вот тут.

Напомним, что продукт позволяет получить следующие возможности в рамках функционала Log Insight:

• Быстрая идентификация проблем за счет специализированных дэшбордов, отображающих состояние кластеров vSAN.
• Возможность использования различных комплексных фильтров для поиска нужной информации в логах vSAN.
• Визуализация необходимых параметров и запросов, что позволяет определить аномалии в различных аспектах инфраструктуры.
• Мощный движок алертинга, который позволяет мониторить логи vSAN на предмет возможных проблем и оповещать администраторов.
• Помощь администраторам - каждый виджет включает информацию о его назначении со ссылками на документацию и базу знаний VMware, что позволяет понять характер и назначение отображаемых данных.

Давайте посмотрим, что нового появилось в версии Log Insight Content Pack for vSAN 2.2:

1. Новый дэшборд vSAN Overview.

Он отображает основные активности и события, происходящие как на пользовательском уровне, так и на уровне ядра. События разделяются на общую информацию, предупреждения и ошибки.

Это позволяет быстрее обнаруживать аномалии в поведении кластера VMware vSAN.

2. Новый раздел Storage Policy Events.

Он включает в себя мониторинг следующих активностей:

• Создание и удаление новых политик хранилищ.
• Изменение политики для ВМ или назначение ей новой политики.
• Изменение свойств самой политики.
• Изменение политик на уровне объектов.

Механизм обновления контент-пака

Для Log Insight механизм обновления контент-паков всегда был весьма простым:

После обновления контент-пака у вас появятся новые дэшборды, описанные выше, но чтобы появились виджеты политик хранилищ, нужно установить Log Insight Agent на vCenter Server. Для этого нужно загрузить пакет Linux RPM (32-bit/64-bit) через Log Insight Administration UI:

После этого нужно скопировать RPM во временную папку на vCenter Server с помощью WinSCP или Veeam FastSCP. Далее на vCSA нужно запустить следующую команду:

rpm -i VMware-Log-Insight-Agent-<version-and-build-number>.rpm

После установки пакета нужно убедиться, что соответствующий статус отображается в интерфейсе:

Далее настройте и включите vCenter (Linux) SPBM agent group на сервере vCenter как показано ниже (это позволит Log Insight собирать события SPBM с сервера vCenter):

После того, как вы нажмете кнопку Copy Template, вам покажут настройки активного агента. Убедитесь, что все параметры указаны корректно и нажмите Save Agent Group:

Новые возможности по трекингу активностей SPBM позволят вам выполнять следующие задачи:

• Отслеживать резкие изменения в используемой емкости кластера.
• Идентифицировать причины неожиданных изменений в производительности ВМ.
• Идентифицировать причины инициирования трафика ресинхронизации.
• Отслеживать соблюдение политик хранилищ за пределами уровня кластера.
• Использовать Webhooks для оповещения других приложений, которым может быть полезна информация от Log Insight.

Скачать VMware vRealize Log Insight Content Pack for vSAN 2.2 можно по этой ссылке.

Недавно мы, говоря о главных анонсах конференции VMworld 2019, забыли рассказать об одном из самых главных - релизе продукта для управления и мониторинга виртуальной инфраструктуры VMware vRealize Operations 8.0. Напомним, что о новых возможностях vRealize Operations 7.5 мы писали вот тут. Надо сказать, что несмотря на то, что vROPs 8.0 бы анонсирован еще в августе этого года...

В сентябре этого года мы писали о VMware Cloud Foundation 3.8.1 - комплексном программном решении, которое включает в себя компоненты VMware vRealize Suite, VMware vSphere Integrated Containers, VMware Integrated OpenStack, VMware Horizon, NSX и другие, работающие в онпремизной, облачной или гибридной инфраструктуре предприятия под управлением SDDC Manager.

На днях компания VMware объявила о выходе обновленной архитектуры VMware Cloud Foundation 3.9.

Давайте посмотрим, что нового появилось в VCF 3.9:

• Поддержка апгрейдов на уровне кластера - теперь есть возможность выбрать отдельные кластеры в рамках домена рабочей нагрузки для обновления хостов ESXi.
• Возможность управления несколькими экземплярами Cloud Foundation из одной консоли.
• Домены рабочей нагрузки Virtual Infrastructure (VI) теперь поддерживают Fibre Channel (в дополнение к vSAN и NFS) как Principal Storage.
• Возможность пересборки конфигураций серверов Dell MX под нужды заказчиков.
• В SDDC Manager можно настроить бэкап NSX Managers на сервер SFTP таким образом, чтобы он находился в отдельной зоне отказа (fault zone). Рекомендуется зарегистрировать сервер SFTP на SDDC Manager после обновления и во время первоначальной настройки.
• Бета-возможность Developer Center - она позволяет получить доступ к Cloud Foundation API и примерам кода под SDDC Manager Dashboard.
• Поддержка Cloud Foundation API была существенно расширена, подробнее об этом рассказано тут.
• Bill of Materials (BoM) был обновлен до последних версий продуктов.

Вот список BoM для релиза VCF 3.9:

Project Pacific был одним из главных анонсов конференции VMworld в этом году, и VMware обращала на него особенное внимание. Это неудивительно - ведь VMware делает поддержку Kubernetes не для галочки. Тут дело в том, что многие пользователи планируют развертывание инфраструктуры контейнеризованных приложений на физической инфраструктуре - в этом случае не надо нести издержки на гипервизор и лицензии, а сами приложения в контейнерах работают быстро и имеют встроенные средства обеспечения доступности.

Недавно компания Gartner опубликовала свой магический квадрант и отчет, касающийся расстановки сил среди решений для резервного копирования и восстановления систем современных датацентров (Data Center Backup and Recovery Solutions).

Компания Veeam со своим пакетом решений Veeam Availability Suite заняла в этом квадранте заслуженное место лидера (уже третий год подряд):

Компания Veeam за последнее время сделала немало всего для укрепления своей позиции в секторе лидеров:

• Приобрела компанию N2WS для резервного копирования и восстановления в облаке AWS.
• Разработала технологию DataLabs, которая представляет собой улучшенную версию виртуальных тестовых лабораторий с функцией мгновенного монтирования бэкапов.
• Представила решение Veeam Availability Orchestrator.
• Добавила поддержку систем AIX и Solaris для резервного копирования.
• Добавила нативную поддержку ярусов хранения в облаках AWS, Azure/Azure Stack, IBM Cloud и хранилищах Amazon S3.
• Добавила поддержку решения Nutanix AHV.
• Добавила поддержку дисковых flash-массивов Infinidat и Pure Storage.

Более подробно о решении Veeam Availability Suite можно узнать по этой ссылке.

О магических квадрантах Gartner

Напомним, что Magic Quadrant используется для оценки поставщиков какого-либо сегмента рынка информационных технологий, где Gartner использует две линейные прогрессивные экспертные шкалы:

• полнота видения (completeness of vision)
• способность реализации (ability to execute)

Каждый поставщик, попавший в рамки рассмотрения для исследуемого сегмента рынка, оценивается по этим двум критериям. При этом, полнота видения откладывается на оси абсцисс, способность реализации — на оси ординат. Каждый поставщик, таким образом, оказывается в одном из четырёх квадрантов плоскости, называемых:

• Лидеры (leaders) — поставщики с положительными оценками как по полноте видения, так и по способности реализации.
• Претенденты (challengers) — поставщики с положительными оценками только по способности реализации.
• Провидцы (visionaries) — поставщики с положительными оценками только по полноте видения.
• Нишевые игроки (niche players) — поставщики с отрицательными оценками по обоим критериям.

В последних числах августа компания StarWind Software, выпускающая продукты для организации хранилищ под виртуализацию, выпустила обновленную версию решения для создания iSCSI-хранилищ на платформах vSphere и Hyper-V - StarWind Virtual SAN V8 build 13182. Давайте посмотрим, что нового появилось в этом продукте...

Некоторое время назад мы писали о новых возможностях решения для создания отказоустойчивых хранилищ на базе хост-серверов VMware vSAN 6.7 Update 3. Среди прочего там появилось пара расширенных настроек, на которые обратил внимание Cormac Hogan. Давайте посмотрим, чем управляют эти Advanced Options в кластере.

Чтобы увидеть новые опции, надо в vSphere Client пойти в Cluster > Configure > vSAN > Services > Advanced Options, где можно увидеть параметры Large Cluster Support и Automatic Rebalance:

Первая настройка, как понятно из названия, регулирует возможность создания кластеров, которые имеют более 32 узлов. Ранее, чтобы расширить кластер, нужно было выставить параметр TcpipHeapMax на всех его хост-серверах ESXi. Теперь это удобно сделано в Advanced Options и применяется на уровне всего кластера.

Настройка Large Cluster Support требует перезагрузки каждого из хост-серверов:

Если вы не перезагрузите хосты, что в разделе статуса "vSAN extended configuration in sync" будут отображаться ошибки:

Вторая настройка, Automatic Rebalance, относится к дисковым объектам кластера vSAN, которые распределяются по дисковым группам разных хостов. Если данная настройка включена, то кластер vSAN автоматически наблюдает за балансом распределения дисковых объектов по хостам ESXi и выравнивает нагрузку на дисковые устройства. По умолчанию пороговое значение составляет 30%, что означает, что когда разница нагрузки между двумя дисковыми устройствами достигнет этого значения - начнется перебалансировка и перемещение дисковых объектов. Она будет продолжаться, пока это значение не снизится до 15% или меньшей величины.

Также в разделе vSAN Disk Balance вы найдете информацию по использованию дисковой подсистемы кластера:

В случае, если у вас включена настройка Automatic Rebalance, кластер vSAN будет стараться поддерживать этот хэлсчек всегда зеленым. Если же отключена - то в случае возникновения дисбаланса загорится алерт, и администратору нужно будет вручную запустить задачу Rebalance Disks.

На блогах VMware появилась интересная статья о том, как работает связка кэширующего яруса (Cache tier) с ярусом хранения данных (Capacity tier) на хостах кластера VMware vSAN в контексте производительности. Многие пользователи задаются вопросом - а стоит ли ставить более быстрые устройства на хосты ESXi в Capacity tier и стоит ли увеличивать их объем? Насколько это важно для производительности?

Системы кэширования работают в датацентре на всех уровнях - это сетевые коммутаторы, процессоры серверов и видеокарт, контроллеры хранилищ и т.п. Основная цель кэширования - предоставить высокопроизводительный ярус для приема операций ввода-вывода с высокой интенсивностью и малым временем отклика (это обеспечивают дорогие устройства), после чего сбросить эти операции на постоянное устройство хранения или отправить в нужный канал (для этого используются уже более дешевые устройства).

В кластере vSAN это выглядит вот так:

Второе преимущество двухъярусной архитектуры заключается в возможности манипуляции данными не на лету (чтобы не затормаживать поток чтения-записи), а уже при их сбрасывании на Capacity tier. Например, так работают сервисы компрессии и дедупликации в VMware vSAN - эти процессы происходят уже на уровне яруса хранения, что позволяет виртуальной машине не испытывать просадок производительности на уровне яруса кэширования.

Общая производительность двухъярусной системы зависит как от производительности яруса хранения, так и параметров яруса кэширования (а именно скорость работы и его объем). Ярус кэширования позволяет в течение определенного времени принимать операции ввода-вывода с очень большой интенсивностью, превышающей возможности приема яруса хранения, но по прошествии этого времени буфер очищается, так как требуется время для сброса данных на уровень постоянного хранения.

С точки зрения производительности это можно представить так (слева система с ярусом кэширования и хранения, справа - только с ярусом хранения):

Оказывается, в реальном мире большинство профилей нагрузки выглядят именно как на картинке слева, то есть система принимает большую нагрузку пачками (burst), после чего наступает некоторый перерыв, который устройства кэширования кластера vSAN используют для сброса данных на постоянные диски (drain).

Если вы поставите более производительное устройство кэширования и большего объема, то оно сможет в течение большего времени и быстрее "впитывать" в себя пачки операций ввода-вывода, которые возникают в результате всплесков нагрузки:

Но более быстрое устройство при равном объеме будет "наполняться" быстрее при большом потоке ввода-вывода, что уменьшит время, в течение которого оно сможет обслуживать такие всплески на пиковой скорости (зато во время них не будет проблем производительности). Здесь нужно подбирать устройства кэширования именно под ваш профиль нагрузки.

С точки зрения устройств кэширования и хранения, кластер VMware vSAN представлен дисковыми группами, в каждой из которых есть как минимум одно устройство кэширования и несколько дисков хранения:

Для устройств кэширования на уровне одной дисковой группы установлен лимит в 600 ГБ. Однако это не значит, что нельзя использовать ярус большего объема. Мало того, некоторые пользователи vSAN как раз используют больший объем, так как в этом случае запись происходит во все доступные ячейки SSD (но суммарный объем буфера все равно не превышает лимит), что приводит к меньшему изнашиванию устройств в целом. Например, так происходит в кластере All-flash - там все доступная свободная емкость (но до 600 ГБ) резервируется для кэша.

Надо еще понимать, что если вы поставите очень быстрые устройства кэширования, но небольшого объема - они будут быстро заполняться на пиковой скорости, а потом брать "паузу" на сброс данных на ярус хранения. Таким образом, здесь нужен компромисс между объемом и производительностью кэша.

На базе сказанного выше можно дать следующие рекомендации по оптимизации производительности двухъярусной системы хранения в кластерах VMware vSAN:

• Старайтесь использовать устройства кэширования большего объема, чтобы они могли впитывать большой поток ввода-вывода в течение большего времени. Производительность устройств уже рассматривайте во вторую очередь, только если у вас уж очень большой поток во время всплесков, который нужно обслуживать очень быстро.
• Добавляйте больше дисковых групп, каждую из которых может обслуживать свое устройство кэширования. На уровне дисковой группы установлен лимит в 600 ГБ, но всего на хосте может быть до 3 ТБ буфера, поделенного на 5 дисковых групп.
• Используйте более производительные устройства в ярусе хранения - так сброс данных буфера (destage rate) на них будет происходить быстрее, что приведет к более быстрой готовности оного обслуживать пиковую нагрузку.
• Увеличивайте число устройств хранения в дисковой группе - это увеличит скорость дестейджинга данных на них в параллельном режиме.
• Отслеживайте производительность кластера с помощью vSAN Performance Service, чтобы увидеть моменты, когда ярус кэширования захлебывается по производительности. Это позволит соотнести поведение буфера и профиля нагрузки и принять решения по сайзингу яруса кэширования и яруса хранения.
• Используйте самые последнии версии VMware vSAN. Например, в vSAN 6.7 Update 3 было сделано множество программных оптимизаций производительности, особенно в плане компрессии и дедупликации данных. Всегда имеет смысл быть в курсе, что нового появилось в апдейте и накатывать его своевременно.

Это гостевой пост сервис-провайдера ИТ-ГРАД, предоставляющего в аренду виртуальные машины из облака. Вы наверняка много раз видели эпические фотографии из ЦОД-ов, в которых за горизонт уходят стойки забитые серверами, установлены мощные генераторы и системы кондиционирования. Многие любят хвастаться такими кадрами, но меня всегда интересовало, а как операторы ЦОД-ов выбирают и настраивают своё оборудование?
Таги: IT-Grad, IaaS, Datacenter, Enterprise, Cloud

Анонсы VMworld 2019 - часть 5. Новые возможности VMware vCloud Director 10.

На прошедшей конференции VMworld 2019 компания VMware анонсировала новую (юбилейную) версию интегрированной платформы для сервис-провайдеров, предоставляющих виртуальные машины в аренду - VMware vCloud Director 10 (vCD). Напомним, что версия vCloud Director 9.5 была анонсирована ровно год назад на VMworld 2018, с тех пор был выпущен еще vCloud Director 9.7.

Daniel Paluszek сделал 2 интересных поста о новых возможностях VMware vCloud Director 10 (раз и два), основные моменты из которых мы приводим ниже.

vCloud Director - это главное средство для партнеров VMware Cloud Providers, которые работают с множеством клиентов, потребляющих услуги виртуальных датацентра из облаков в целях создания единой гибридной среды для своего предприятия.

Новый релиз vCD 10 сфокусирован на 3 основных аспектах:

• Улучшения механизмов для доставки виртуальных сервисов и обслуживания клиентов облака.
• Многопрофильные нагрузки. Теперь vCloud Director - это не только про виртуальные машины, он поддерживает интеграцию с такими сервисами, как PKS, чтобы обеспечить клиентам наиболее удобный способ использования приложений в виртуальном датацентре.
• Улучшения рабочих процессов в интерфейсе и их упрощение для клиентов.

Давайте посмотрим, что нового появилось в VMware vCloud Director 10:

1. Полный переход на интерфейс Clarity.

Теперь vCD 10 полностью работает на базе HTML5-фреймворка Clarity, который представляет интерфейс просто и четко, в рамках общей концепции остальных продуктов VMware (vSphere, Horizon, NSX).

Интерфейс Flex еще сохранился как резервный, но он будет отсутствовать в следующей версии, да и сейчас он остался лишь на всякий случай.

2. Переработаны мастера создания новых объектов.

VMware уделила большое внимание тому, как именно сервис-провайдеры создают сущности и дала пояснения к ним:

Создание пула выглядит понятнее:

В менюшке есть удобная справка по ресурсам как для самого vCD, так и для платформы vSphere:

3. Поддержка VMware NSX-T.

Новый релиз vCD 10 сфокусирован на создании функциональных сетевых сервисов в среде NSX-T. Пока работа еще не закончена (как это было сделано с NSX-V), но движение вперед уже есть.

Creation Workflow теперь выглядит проще и понятнее:

При добавлении нового oVDC мы можем видеть наш NSX-T Overlay pool:

Для NSX-T доступны следующие функции...Читать статью далее->>

Многие из вас следят за новостями и событиями конференции VMworld 2019, которая проходит в эти дни в Сан-Франциско. Одним из первых и важных анонсов конференции стало объявление о скором выпуске проекта VMware Tanzu. Те из вас, кто следит в последнее время за новыми релизами от VMware, знают, что компания выпускает очень много чего интересного для инфраструктуры контейнеризованных приложений Kubernetes.

Например, совсем недавно мы писали о новой подсистеме хранения для K8s - Cloud Native Storage (CNS), утилите для контроля и мониторинга состояния кластеров VMware Octant, а также средстве для управления инфраструктурой контейнеров приложений VMware Enterprise PKS 1.5 (Pivotal Container Service).

На данный момент свежепоявившееся семейство Tanzu представлено двумя продуктами:

• Project Pacific — набор средств для преобразования среды VMware vSphere в нативную платформу для кластеров Kubernetes (будет доступно в следующих релизах vSphere).
• VMware Tanzu Mission Control - единая операционная консоль для кластеров Kubernetes, которая позволит контролировать все аспекты жизненного цикла приложений.

Project Pacific

Project Pacific сейчас находится в статусе технологического превью. Это средство представляет собой набор инструментов, который позволяет преобразовать платформу vSphere в средство нативного исполнения приложений в среде Kubernetes.

Данный продукт будет решать следующие задачи:

• Использование vSphere для нативной среды Kubernetes
• Предоставление средств управления, сфокусированных на приложениях
• Возможность взаимодействия команд разработки и администрирования/оперирования

С помощью Pacific разработчики продолжат управлять приложениями посредством Kubernetes, но сами приложения за счет этого будут "комфортно себя чувствовать" на платформе ESXi. Администраторы же смогут выполнять рутинные задачи через средства управления VMware vCenter.

Так как подразумевается, что Kubernetes будет нативно работать в среде vSphere, то будет поддерживаться концепция пространств имен в рамках инфраструктуры vSphere. Пространства имен в K8s - это коллекции объектов (контейнеры, виртуальные машины, диски и т.п.).

На уровне пространств имен в среде K8s можно выполнять стандартные для vSphere операции, такие как контроль и выделение ресурсов, vMotion, шифрование, HA и снапшоты.

VMware Tanzu Mission Control

Tanzu MC дает менеджерам и администраторам датацентров средства для создания и развертывания новых приложений на платформе Kubernetes, а также дает управлять кластерами K8s из единой точки. Таким образом, команды разработки могут запросить нужные ресурсы, когда им требуется, и получить их самым быстрым и оптимальным образом.

Платформа Tanzu Mission Control полностью построена на базе универсального API, который могут использовать разработчики для оперирования кластерами Kubernetes через Cluster API. Это касается всех рабочих процессов (например, создание или обновление кластера), а также аутентификации и прочих вспомогательных сервисов.

Сама консоль - это SaaS-решение, которое объединяет объекты разной природы в облачной консоли (например, это могут быть компоненты платформы vSphere, объекты из публичных облаков, средства OpenShift или просто самопальные инсталляции собственной архитектуры). Также вы можете привязать кластер VMware Essential PKS к консоли Tanzu Mission Control и использовать средства автоматизации обслуживания жизненного цикла кластеров, либо можно открыть и использовать расширенные средства сервисов PKS-кластера.

Консоль Mission Control использует:

• Cluster API для управления жизненным циклом (Lifecycle Management)
• Velero для резервного копирования и восстановления
• Sonobuoy для контроля конфигураций
• Contour для контроля компонентов ingress

Также все кластеры и их объекты покрываются гибко настраиваемыми политиками. Их можно применять к кластерам и группам кластеров, разграничивая таким образом зоны ответственности между разработчиками.

Ну и одно из самых удобных для оператора - это федерация данных кластеров K8s из разных источников в единой консоли:

Более подробно о проекте Tanzu можно почитать в пресс-релизе VMware.

Год назад компания StarWind Software анонсировала собственный таргет и инициатор NVMe-oF для Hyper-V, с помощью которых можно организовать высокопроизводительный доступ к хранилищам на базе дисков NVMe (подключенных через шину PCI Express) из виртуальных машин. За прошедший год StarWind достаточно сильно улучшила и оптимизировала этот продукт и представила публично результаты его тестирования.

Для проведения теста в StarWind собрали стенд из 12 программно-апаратных модулей (Hyperconverged Appliances, HCA) на базе оборудования Intel, Mellanox и SuperMicro, составляющий высокопроизводительный вычислительный кластер и кластер хранилищ, где подсистема хранения реализована с помощью продукта Virtual SAN, а доступ к дискам происходит средствами инициатора NVMe-oF от StarWind. Между хостами был настроен 100 Гбит Ethernet, а диски SSD были на базе технологии NVMe (P4800X). Более подробно о конфигурации и сценарии тестирования с технологией NVMe-oF написано тут.

Аппаратная спецификация кластера выглядела так:

• Platform: Supermicro SuperServer 2029UZ-TR4+
• CPU: 2x Intel® Xeon® Platinum 8268 Processor 2.90 GHz. Intel® Turbo Boost ON, Intel® Hyper-Threading ON
• RAM: 96GB
• Boot Storage: 2x Intel® SSD D3-S4510 Series (240GB, M.2 80mm SATA 6Gb/s, 3D2, TLC)
• Storage Capacity: 2x Intel® Optane™ SSD DC P4800X Series (375GB, 1/2 Height PCIe x4, 3D XPoint™). The latest available firmware installed.
• RAW capacity: 9TB 
• Usable capacity: 8.38TB 
• Working set capacity: 4.08TB 
• Networking: 2x Mellanox ConnectX-5 MCX516A-CCAT 100GbE Dual-Port NIC
• Switch: 2x Mellanox SN2700 32 Spectrum ports 100GbE Ethernet Switch

Схема соединений тестового стенда:

Для оптимизации потока ввода-вывода и балансировки с точки зрения CPU использовался StarWind iSCSI Accelerator, для уменьшения latency применялся StarWind Loopback Accelerator (часть решения Virtual SAN), для синхронизации данных и метаданных - StarWind iSER initiator.

Как итог, ввод-вывод оптимизировался такими технологиями, как RDMA, DMA in loopback и TCP Acceleration.

С точки зрения размещения узлов NUMA было также сделано немало оптимизаций (кликните для увеличения):

Более подробно о механике самого теста, а также программных и аппаратных компонентах и технологиях, рассказано здесь. Сначала тест проводился на чистом HCA-кластере без кэширования.

Результаты для 4К Random reads были такими - 6,709,997 IOPS при теоретически достижимом значении 13,200,000 IOPS (подробнее вот в этом видео).

Далее результаты по IOPS были следующими:

• 90% random reads и 10% writes = 5,139,741 IOPS
• 70% random reads и 30% writes = 3,434,870 IOPS

Полная табличка выглядит так:

Потом на каждом хосте Hyper-V установили еще по 2 диска Optane NVMe SSD и запустили 100% random reads, что дало еще большую пропускную способность - 108.38 GBps (это 96% от теоретической в 112.5 GBps.

Для 100% sequential 2M block writes получили 100.29 GBps.

Полные результаты с учетом добавления двух дисков:

А потом на этой же конфигурации включили Write-Back cache на уровне дисков Intel Optane NVMe SSD для каждой из ВМ и для 100% reads получили 26,834,060 IOPS.

Полная таблица результатов со включенным кэшированием выглядит так:

Да-да, 26.8 миллионов IOPS в кластере из 12 хостов - это уже реальность (10 лет назад выжимали что-то около 1-2 миллионов в подобных тестах). Это, кстати, 101.5% от теоретического максимального значения в 26.4М IOPS (12 хостов, в каждом из которых 4 диска по 550 тысяч IOPS).

Для тестов, когда хранилища были презентованы посредством технологии NVMe-oF (Linux SPDK NVMe-oF Target + StarWind NVMe-oF Initiator), было получено значение 22,239,158 IOPS для 100% reads (что составляет 84% от теоретически расчетной производительности 26,400,000 IOPS). Более подробно об этом тестировании рассказано в отдельной статье.

Полные результаты этого теста:

Все остальное можно посмотреть на этой странице компании StarWind, которая ведет учет результатов. Зал славы сейчас выглядит так :)

Как вы знаете, недавно обновленная платформа виртуализации VMware vSphere 6.7 Update 3 стала доступной для загрузки. Одновременно с этим компания VMware сделала доступной для скачивания и развертывания систему отказоустойчивых кластеров хранилищ VMware vSAN 6.7 Update 3. В обоих этих решениях появилась встроенная поддержка технологии Cloud Native Storage (CNS), о которой мы сегодня расскажем.

Итак, Cloud Native Storage (CNS) - это функциональность VMware vSphere и платформы оркестрации Kubernetes (K8s), которая позволяет по запросу развертывать и обслуживать хранилища для виртуальных машин, содержащих внутри себя контейнеры. По-сути, это платформа для управления жизненным циклом хранения для контейнеризованных приложений.

При этом для такого управления сделано специальное представление в интерфейсе vCenter, которое вы видите на картинке выше.

Основная задача CNS - это обеспечивать развертывание, мониторинг и управление хранилищами для Cloud Native Applications (CNA), то есть современных приложений, исполняемых в контейнерах Docker под управлением Kubernetes (но, кстати, в будущем возможна поддержка и таких платформ, как Mesos и Docker Swarm).

Архитектура CNS реализована двумя компонентами:

• Интерфейс Container Storage Interface (CSI), представляющий собой плагин для K8s.
• Консоль управления CNS Control Plane на сервере vCenter, доступная через vSphere Client.

Через консоль управления CNS администратор может получить представление об имеющихся хранилищах в среде K8s (и видеть маппинги хранилищ на виртуальные диски VMDK), а также управлять ими в большом масштабе, что очень сложно при оперировании на уровне отдельных контейнеров, так как их могут быть сотни на одном хосте ESXi.

Кстати, про оперирование CNS есть интересное видео от VMware:

Надо понимать, что технология CNS появилась не впервые. Ранее подобные функции реализовывал механизм vSphere Storage for Kubernetes (он же vSphere Cloud Provider, VCP). Проект VCP появился как результат внутреннего хакатона VMware, когда требовалось быстро сделать драйвер для кластеров Kubernetes.

До этого приходилось вручную монтировать хранилища контейнеров на виртуальные диски VMDK, что было крайне неудобно, а при большом количестве контейнеров - практически нереально.

Сейчас архитектура VCP реализуется такими решениями Kubernetes as a Service (KaaS), как VMware PKS, RedHat OpenShift, Google Cloud Anthos и Rancher. Для этой архитектуры было возможно 2 режима развертывания - "in-tree" и "out-of-tree". В первом случае VCP был интегрирован в дистрибутив Kubernetes и развертывался одновременно с ним, а во втором - подразумевал последующую интеграцию после развертывания K8s.

Ввиду того, что обновлять VCP при первом варианте развертывания можно было только одновременно с K8s, вариант "in-tree" был исключен из конфигурации развертывания Kubernetes. VMware использовала эту ситуацию для того, чтобы полностью переписать код VCP (который, скорее всего, был не самым оптимальным еще с хакатона) и получить новую архитектуру - CNS.

Также кстати оказалась и покупка компании Heptio (об этом мы упоминали вот тут) - в итоге VMware интегрировала решение CNS прямо в платформу vSphere, без необходимости что-либо развертывать дополнительно. Мало того, архитектура CNS поддерживает любой оркестратор контейнеров, построенный на базе спецификации CSI.

Таким образом, CNS Control Plane на сервере vCenter брокеризует соединение с плагином (на данный момент только для K8s), который уже взаимодействует на уровне Kubernetes.

Частью решения CNS являются First Class Disks (FCDs), о которых мы рассказывали вот тут. Они были придуманы для того, чтобы управлять сервисами, заключенными в VMDK-диски, но не требующими виртуальных машин для своего постоянного существования. Это очень удобно для контейнеров, так как их можно динамически привязывать и отвязывать, не оставляя после себя "осиротевших" VMDK.

Кроме всего этого, CNS полностью подчиняется политикам Storage Policy-Based Management (SPBM), а это значит, что инфраструктура таких хранилищ отлично согласуется с пространством ярусного хранения VMware vSAN и концепцией K8s StorageClass. Также CNS, конечно же, работает и с классическими хранилищами VMFS и NFS, что позволяет использовать политики SPBM на базе тэгов.

Надо отметить, что технология CNS доступна для всех пользователей VMware vSphere, начиная с издания Standard, поэтому платить отдельно за нее не придется. Ну и в заключение обзорное видео о том, что такое и как работает Cloud Native Storage:

Скачать VMware vSphere 6.7 Update 3 с интегрированной технологией CNS можно по этой ссылке.

Перед предстоящей конференцией VMworld 2019, которая состоится на следующей неделе в Сан-Франциско, компания VMware сделала несколько небольших анонсов, чтобы они не потерялись на фоне больших. В частности, стала доступной для скачивания новая версия платформы VMware vSphere 6.7 Update 3, решение VMware vSAN 6.7 Update 3 и продукт VMware PKS 1.5. Ну а на днях было выпущено еще одно обновление фреймворка для управления виртуальной инфраструктурой через PowerShell - VMware PowerCLI 11.4.

Напомним, что о прошлой версии PowerCLI 11.3 мы писали в начале лета вот тут. Давайте посмотрим, что нового появилось в PowerCLI 11.4:

1. Поддержка решения Horizon View 7.9.

Модуль для работы с Horizon View (VMware.VimAutomation.HorizonView) был обновлен, чтобы поддерживать новые возможности решения VMware Horizon 7.9.

2. Обновленный модуль Storage.

В PowerCLI 11.4 был существенно доработан модуль по работе с хранилищами, чтобы поддерживать последнюю версию продукта для создания отказоустойчивых кластеров хранилищ VMware vSAN 6.7 Update 3. Например, были обновлены командлеты Get/Set-VsanClusterConfiguration, которые теперь поддерживают функции Proactive Rebalance и vSphere Update Manager baseline preference.

Вот пример работы с этими функциями в действии (на красный текст внимание не обращайте, он говорит о том, что для работы нужен vSAN 6.7 U3):

Также появилось три новых командлета. Первый - это Add-VsanObjectToRepairQueue, он может восстанавливать объекты, которые добавляются в очередь на восстановление (ранее эта функция была частично доступна в командлете Repair-VsanObject). Второй и третий - это Get-VsanResyncingOverview и Get-VsanEnterMaintenanceMode, они работают с новыми функциями vSAN 6.7 U3.

3. Обновленный модуль HCX.

Теперь в этот модуль было добавлено целых 6 новых командлетов:

• Get-HCXAppliance - возвращает информацию о текущей версии виртуального модуля и доступных версиях.
• Его можно использовать с командлетом New-HCXAppliance - он позволяет проапгрейдить виртуальный модуль на одну из доступных версий.
• Get-HCXContainer - добавляет возможность вывести список контейнеров типа "OrgVdc".
• Get-HCXNetwork - добавляет возможность посмотреть 2 типа сетей: NsxtSegment и OrgVdcNetwork.
• New-HCXNetworkExtension - дает возможность работать с сетями типа NsxtSegment.
• Get-HCXServiceMesh - он имеет свойства, которые дают посмотреть параметры некоторых сервисов.

Пример использования командлетов Get-HCXAppliance и Get-HCXServiceMesh для просмотра нового свойства ServiceStatus:

Командлеты Get-HCXServiceMesh и Get-HCXInterconnectStatus были существенно доработаны, чтобы уметь исправлять ситуацию при различных ошибках. Также свойство DestinationNetworkValue теперь отображается корректно.

Как обычно, обновление модулей PowerCLI происходит командой:

Update-Module -Name VMware.PowerCLI

Больше информации об нововведениях PowerCLI 11.4 приведено в Change Log. Также рекомендуем почитать VMware PowerCLI 11.4.0 User’s Guide. Главный документ с примерами - VMware PowerCLI 11.4.0 Cmdlet Reference.

Недавно на сайте проекта VMware Labs обновилась одна из самых полезных утилит для администраторов хранилищ VMware vSphere – IOBlazer. Она позволяет сгенерировать нагрузку на хранилища с любых платформ - Linux, Windows и Mac OS, при этом администратор может задавать паттерн нагрузки с высокой степенью кастомизации, что очень важно для реального тестирования подсистемы хранения для виртуальных машин.

На сайте проекта VMware Labs появилась очередная интересная утилита - виртуальный модуль vSAN Performance Monitor, предназначенный для мониторинга метрик в среде отказоустойчивых кластеров VMware vSAN и их визуализации.

С помощью vSAN Performance Monitor администратор может на регулярной основе собирать метрики производительности в кластерах vSAN, которые потом визуализуются на уже преднастроенных дэшбордах, встроенных в продукт.

С помощью этих данных администраторы смогут диагностировать проблемы, а также распознавать текущие и намечающиеся узкие места в инфраструктуре, которые могут оказаться причиной низкой производительности.

Напомним, что 5 лет назад была выпущена похожая утилита - vSAN Observer, ну а создатели vSAN Performance Monitor открыто пишут, что при разработке вдохновлялись именно ей.

Само средство поставляется в виде виртуального модуля (Virtual Appliance), который реализует 3 основных компонента:

• Коллектор Telegraf - это агент, который собирает метрики в кластере и сохраняет их в базе данных InfluxDB.
• InfluxDB - собственно, сама база данных, хранящая метрики.
• Grafana - это фреймворк, который используется для визуализации метрик из базы.

После развертывания администратору лишь нужно указать простые настройки и подключить коллектор к одному или нескольким целевым кластерам и стартовать сервис. После этого данные будут собираться на периодической основе и могут быть визуализованы в любой момент.

В качестве платформы и целевой машины для vSAN Performance Monitor поддерживаются vSphere 6.0 и VM hardware 11  (или более поздние). Для работы утилиты вам потребуется включить службу Virtual SAN Performance Service (о том, как это сделать, написано вот тут).

Скачать vSAN Performance Monitor можно по этой ссылке.

Компания VMware на днях объявила о скором выпуске новой версии решения для создания отказоустойчивых кластеров хранилищ - VMware vSAN 6.7 Update 3. Основная тема нововведений - поддержка облачных сред размещения виртуальных машин и работа с контейнеризованными приложениями.

Давайте посмотрим, что именно нового появилось в vSAN 6.7 Update 3:

1. Поддержка контейнеров приложений в облачных средах.

Контейнеры стали одной из главных моделей распространения приложений в облачной среде. Сама технология контейнеризации упрощает развертывание и обслуживание приложений, выделяя их в микросервисы, но все процессы вокруг них становятся сложнее (оркестрация, организация персистентных хранилищ, сетевая коммуникация).

vSAN 6.7 Update 3 имеет встроенные инструменты по организации постоянных хранилищ для контейнеров приложений, в том числе в облачных средах. Технология vSAN cloud native storage поддерживает все ключевые API-вызовы к хранилищам внутри кластеров Kubernetes через драйвер Container Storage Interface (CSI). Теперь разработчики смогут применять политики хранилищ SPBM при развертывании новых pods и монтировании томов с постоянными хранилищами, точно так же, как они делают это с виртуальными дисками машин.

Если же вы используете тома Virtual Volumes на платформе vSAN, то получите еще больше преимуществ:

• Развертывание хранилищ контейнеров через API параллельно с самими контейнерами.
• Возможность портирования приложений между частным и публичным облаком в рамках гибридной среды с поддержкой одного набора операций и инструментов.

2. Нативная гибридная среда инфраструктуры vSAN.

Сейчас гибридные среды становятся очень распространенной моделью доставки ИТ-сервисов, так как именно сочетание частного и публичного облаков дает самый большой эффект с точки зрения масштабирования и обеспечения показателей качества предоставления услуг. При этом администраторы хотят, чтобы приложения Docker также имели возможность бесшовно перемещаться между публичным и частным облаками со всеми их хранилищами.

Теперь vSAN предоставит интеграцию с сотнями облачных провайдеров, включая "большую четверку" Amazon, Microsoft, Google и IBM, которая позволит использовать тот же набор средств и утилит vSAN для хранилищ контейнеров в облаке, что и в частной инфраструктуре.

3. Унифицированные средства управления vSAN для контейнеров и виртуальных машин.

В одной виртуальной машине может быть много контейнеров приложений, вплоть до нескольких сотен. При возникновении проблем с хранилищем для одного из контейнеров становится очень и очень сложно понять ее причину. Теперь же vSAN предоставляет администраторам гранулярную видимость внутри ВМ до уровня контейнеров, что позволяет мониторить состояние отдельных хранилищ контейнеров на уровне томов для каждого из них.

В рамках единого пространства хранения можно анализировать использование емкости виртуальными машинами и контейнерами:

Все это позволит командам DevOps быстрее решать проблемы с хранилищами контейнеризованных приложений через стандартную консоль vSphere Client.

4. Интеллектуальные средства управления вводом-выводом.

Теперь vSAN еще более эффективно работает при обмене данными между буффером на чтение (write buffer) и пространством хранения (capacity tier). Особенно заметна эта оптимизация для последовательных операций записи (что очень актуально для процессов ресинхронизации и восстановления данных).

Адаптивная ресинхронизация теперь идет в рамках множества параллельных потоков, что увеличивает ее эффективность:

Также в vSAN 6.7 U3 появились дополнительные метрики, касающиеся использования CPU хост-серверов ESXi (особенно актуально для дедупликации, шифрования и компрессии). Кроме того, появилась новая команда vsantop, которая показывает эти и многие другие полезные метрики:

5. Прочие улучшения.

Тут собраны различные улучшения vSAN 6.7 Update 3:

• Механизмы управления емкостью были улучшены таким образом, чтобы запускать операцию ресинхронизации на базе доступной емкости. Если какая-то дисковая группа заполнена, то операции ресинхронизации ставятся на паузу, чтобы предотвратить повреждения хранилищ.
• Администратор может выбрать опцию автоматической или ручной ребалансировки данных в кластере. Така как каждая инфраструктура индивидуальна, доступна тонкая настройка механизма ребалансировки, в зависимости от потребностей администратора.
• Теперь применения политик SPBM идут пачками, что существенно ускоряет производительность при изменении структуры политик.
• Выполнение обслуживания или изменении конфигурации во время операций ресинхронизации может привести к неправильному завершению этого процесса, поэтому в SAN 6.7 U3 клиент vSphere Client лучше понимает, когда выполняется этот процесс, и не дает мешать ему.
• Механизм pre-check симуляции, который позволяет администратору понять, что произойдет в случае изменения конфигурации кластера или его обслуживания.
• При изменении конфигурации шифрования, компрессии или дедупликации требуется изменения формата дисков (Disk format changes, DFC). Если для этого процесса недостаточно ресурсов, то специальная проверка даст знать об этом еще до выполнения операции.
• vSAN теперь сам предлагает обновиться на новый мажорный релиз или накатить обновления.
• Ранее vSAN требовал, чтобы vCenter был той же версии или более новый, теперь же поддержка прошлых версий vCenter стала более гибкой.
• Теперь в vSAN 6.7 U3 проще включить vSAN Support Insight и взаимодействовать с поддержкой VMware.
• iSCSI LUN, презентованные из vSAN, теперь можно ресайзить без необходимости переводить том в оффлайн.
• SCSI-3 persistent reservations (SCSI-3 PR) теперь дают возможность нативной поддержки кластеров Windows Server Failover Clusters (WSFC), требующих общего диска.

Издание vSAN Enterprise Plus

Да, теперь VMware, как и для многих других продуктов, вводит издание Enterprise Plus для платформы vSAN. Эта лицензия будет включать в себя комбинацию продукта vSAN Enterprise и средства управления облачной средой vRealize Operations Advanced.

Все это даст следующую функциональность в связке двух решений:

• Географически растянутые кластеры с возможностями локальной защиты и синхронной репликацией.
• Средства нативного шифрования vSAN Encryption с поддержкой дедупликации и компрессии. В качестве провайдеров KMIP можно использовать такие решения, как CloudLink, Hytrust, SafeNet, Thales и Vormetric.
• Постоянная оптимизация производительности с возможностями предиктивной аналитики и проактивного планирования.
• Возможность интеллектуального решения проблем и продвинутый траблшутинг на базе аналитики метрик и логов с использованием средств обзора приложений на уровне всей инфраструктуры.

Более подробно о VMware vSAN 6.7 Update 3 мы узнаем на предстоящей конференции VMworld 2019, которая пройдет в конце августа в Сан-Франциско.

Как многие из вас знают, с 25 по 29 августа в Сан-Франциско пройдет главная конференция года в области виртуализации - VMworld 2019. На конференции будут представлены сотни докладов, практических семинаров и лабораторных работ, поэтому планировать свое время нужно заранее.

Напомним, что конференцию можно посетить не только лично, но и посмотреть онлайн. Чтобы найти подходящую вам сессию, нужно воспользоваться вот этим порталом поиска. На данный момент там представлено 1032 материала:

Кстати, не забывайте и об онлайн-библиотеке материалов VMworld 2018.

Ну а для тех, кому лень искать по всем этим сотням докладов, блоггер Дункан Эппинг выпустил свой список топ-25 сессий, который мы приведем ниже:

• 60 Minutes of Non-Uniform Memory Architecture [HBI2278BU] от Frank Denneman - все самое главное об архитектуре NUMA на платформе vSphere.
• A Practitioner’s Guide to vCenter Server Architecture [HBI2227BU] от Emad Younis и Sandeep Byreddy - больше подробностей об архитектуре vCenter.
• HCI Management: Current and Future [HCI1207BU] от Junchi Zhang и Christian Dickmann - демонстрация возможностей гиперконвергентной инфраструктуры.
• “If This Then That” for vSphere – The Power of Event-Driven Automation [HCI1379CU] от William Lam и Michael Gasch - средства автоматизации vSphere на базе триггеров событий.
• Hyperconverged Infrastructure: Present and Future [HCI2733BU] от Vijay Ramachandran - о будущем средств управления гиперконвергентной инфраструктурой.
• VMware CTO Panel: What’s Over the Horizon? [OCTO2899PU] от Ray O’Farrell, Pere Monclus, Greg Lavender и Christos Karamanolis - все самые последние новости об инфраструктуре виртуальных ПК VMware Horizon.
• The Virtually Speaking Podcast Live: The Future of Storage [HCI1894PU] от Pete Flecha, John Nicholson, и Ken Werneburg - сессия и живой подкаст о хранилищах.
• PowerCLI Deep Dive [HBI1729BU] от Kyle Ruddy и Luc Dekens - все самое интересное от гуру PowerCLI.
• vSphere Virtual Volumes: Technical Deep Dive [HBI2853BU] от Jason Massae и Thiruvengada Govindan Thirumal - одна из самых интересных сессий, так как именно функциональность VVols развивается самыми мощными темпами.
• VMware Cloud on AWS: SDDC Availability Deep Dive [HBI1924BU] от Jeremiah Megie и Glenn Sizemore - доступность ВМ и данных в публичном облаке - это то, что волнует очень многих.
• Zero to DR in 60 Minutes: VMware Site Recovery DRaaS Technical Deep Dive [HBI1229BU] от Stefan Tsonev и Cato Grace - все самое свежее о катастрофоустойчивых решениях VMware.
• Extreme Performance Series - это маст си о производительности платформы VMware vSphere, где нам покажут новые максимумы платформы и достижения в сфере высокой производительности.
• How GPU-Assisted ML for Medical Research Proved to Be a Force for Good [HBI1546BU] от Niels Hagoort и Johan van Amersfoort - прикладная демонстрация использования алгоритмов машинного обучения на платформе виртуализации. Модно.
• One Storage Platform for Thousands of Cloud Providers [HBI2537PU] от Ari Paul, Rawlinson Rivera и John Toor - рассказ о возможностях S3-совместимого объектного хранилища и vCloud Director для сервис-провайдеров.
• Core Storage Best Practices: Ensuring Your Storage Is Reliable [HBI2751BU] от Jason Massae и Cody Hosterman - на это обязательно надо сходить. Лекция от гуру подсистемы хранения vSphere (VMFS, NFS, VAAI и т.п.).
• Optimizing vSAN for Performance [HCI1757BU] от Paudie O’Riordan - крутая лекция о производительности vSAN.
• Showcase Keynote: Hybrid Cloud Architecture – The New Standard from the Data Center [HYB3544KU] от Kit Colbert, Raghu Raghuram и Mark Lohmeyer - о будущем виртуальных датацентров.
• vSphere Networking in the Data-Centric Future [HBI2136BU] от Sudhansu Jain и Disha Chopra - нам расскажут, что нового ожидается в сетевом стеке датацентров будущего.
• Innovations in vMotion: Features, Performance, and Best Practices [HBI1421BU] от Sreekanth Setty и Arunachalam Ramanathan - что нового еще может быть в vMotion? А вот и расскажут)
• VMware Cloud on Dell EMC: Technical Deep Dive [HBI1975BU] от Mike Hall и Sridevi Ravuri - раньше это называлось Project Dimension. Это создание облачной инфраструктуры SDDC, но на площадке заказчика.
• Encrypting VMs on Standalone Hosts: Tech Preview [HBI1947BU] от Mike Foley и Samyuktha Subramanian - что-то новое о шифровании ВМ.
• Diversity and Inclusion Tech Panel: You Can Drive Success for Women in Tech [PD2632U] от Jodi Shely - оффтопик об участии женщин в ИТ.
• Accelerating Intra-Host PVRDMA Storage Traffic in a Future Dell AMD Server [OCTO2718BU] от Richard Brunner и Shyamkumar Iyer - немного дип-тек хардкора для любителей.
• Edge Computing Innovations in Office of the CTO and Dell Technologies [EIOT2715BU] от Chris Wolf и Daniel Beveridge - новые возможности технологий VMware и Dell от CTO VMware.
• How to Become the Platform Engineer of the Future [PD2248U] от Martijn Baecke и Matthew Steiner - как стать работником будущего, быть актуальным и заработать много денег)

Конечно же, как и всегда, мы будем освещать VMworld 2019. Смотрите также наши обзоры с прошлых конференций:

• VMworld 2018
• VMworld 2017
• VMworld 2016
• VMworld 2015
• VMworld 2014
• VMworld 2013
• VMworld 2012
• VMworld 2011
• VMworld 2010
• VMworld 2009
• VMworld 2008
• VMworld 2007

Многие из администраторов VMware vSphere знают про механизм Storage I/O Control (SIOC) в платформе VMware vSphere (см. также наш пост здесь). Он позволяет приоритезировать ввод-вывод для виртуальных машин в рамках хоста, а также обмен данными хостов ESXi с хранилищами, к которым они подключены.

Сегодня мы поговорим о SIOC версии 2 и о том, как он взаимодействует с политиками Storage Policy Based Management (SPBM). Начать надо с того, что SIOC v2 полностью основан на политиках SPBM, а точнее является их частью. Он позволяет контролировать поток ввода-вывода на уровне виртуальных машин.

SIOC первой версии работает только с томами VMFS и NFS, тома VVol и RDM пока не поддерживаются. Он доступен только на уровне датасторов для регулирования потребления его ресурсов со стороны ВМ, настраиваемого на базе шар (shares). Там можно настроить SIOC на базе ограничения от пиковой пропускной способности (throughput) или заданного значения задержки (latency):

На базе выделенных shares виртуальным машинам, механизм SIOC распределит пропускную способность конкретного хранилища между ними. Их можно изменять в любой момент, перераспределяя ресурсы, а также выставлять нужные лимиты по IOPS:

Надо отметить, что SIOC v1 начинает работать только тогда, когда у датастора есть затык по производительности, и он не справляется с обработкой всех операций ввода-вывода.

Если же мы посмотрим на SIOC v2, который появился в VMware vSphere 6.5 в дополнение к первой версии, то увидим, что теперь это часть SPBM, и выделение ресурсов работает на уровне виртуальных машин, а не датасторов. SIOC v2 использует механизм vSphere APIs for I/O Filtering (VAIO), который получает прямой доступ к потоку ввода-вывода конкретной ВМ, вне зависимости от того, на каком хранилище она находится.

Таким образом, вы можете использовать SIOC v2 для регулирования потребления машиной ресурсов хранилища в любой момент, а не только в ситуации недостатка ресурсов.

Поэтому важно понимать, что SIOC v1 и SIOC v2 можно использовать одновременно, так как они касаются разных аспектов обработки потока ввода-вывода от виртуальных машин к хранилищам и обратно.

SIOC v2 включается в разделе политик SPBM, в секции Host-based rules:

На вкладке Storage I/O Control можно выбрать предопределенный шаблон выделения ресурсов I/O, либо кастомно задать его:

Для выбранной политики можно установить кастомные значения limit, reservation и shares. Если говорить о предопределенных шаблонах, то вот так они выглядят для варианта Low:

Так для Normal:

А так для High:

Если выберите вариант Custom, то дефолтно там будут такие значения:

Лимит можно задать, например, для тестовых машин, где ведется разработка, резервирование - когда вы точно знаете, какое минимальное число IOPS нужно приложению для работы, а shares можете регулировать долями от 1000. Например, если у вас 5 машин, то вы можете распределить shares как 300, 200, 100, 100 и 100. Это значит, что первая машина будет выжимать в три раза больше IOPS, чем последняя.

Еще один плюс такого назначения параметров SIOC на уровне ВМ - это возможность определить политики для отдельных дисков VMDK, на которых может происходить работа с данными разной степени интенсивности:

После того, как вы настроили политики SIOC v2, вы можете увидеть все текущие назначения в разделе Monitor -> Resource Allocation -> Storage:

Мы часто пишем о томах VVols (Virtual Volumes), которые позволяют вынести часть нагрузки по обработке операций с хранилищами на сторону аппаратных устройств (они, конечно же, должны поддерживать эту технологию), что дает пользователям преимущества по сравнению с VMFS. В инфраструктуре VVols массив сам определяет, каким образом решать задачи доступа и организации работы с данными для виртуальных машин, выделяя для их объектов (виртуальные диски и прочее) отдельные логические тома (VVols).

Один из известных производителей, поддерживающих технологию VVols - это компания Pure Storage. Недавно Cody Hosterman написал статью о том, как подключить тома VVols в VMware vSphere через PowerCLI для хранилищ Pure Storage. Коди развивает свой модуль PowerShell, который называется PureStorage.FlashArray.VMware.

Давайте посмотрим, как он работает. Сначала можно почитать о доступных опциях командлета Mount-PfaVvolDatastore, с помощью которого можно сделать монтирование датастора VVol:

Командлет может делать следующее:

• Проверяет, презентован ли protocol endpoint (PE) указанного массива кластеру. Если нет, то с его помощью можно сделать это.
• Ресканирует кластер, чтобы убедиться, что PE виден хостам.
• Монтирует VVol в кластере.
• Возвращает датастор хранилищу.

Пример 1 - имеется прямой доступ к массиву

Соединяемся с vCenter и создаем соединение с FlashArray:

connect-viserver -Server <vCenter FQDN>
$flasharray = new-pfaConnection -endpoint <FlashArray FQDN> -credentials (get-credential) -ignoreCertificateError -nonDefaultArray

В интерфейсе vSphere Client датастор VVol еще не будет смонтирован:

Со стороны Pure Storage protocol endpoint также не подключен:

Запускаем Mount-PfaVvolDatastore:

Mount-PfaVvolDatastore -flasharray $flasharray -cluster (get-cluster <cluster name>) -datastoreName <datastore name>

После этого PE будет подключен к Pure Storage:

А датастор VVol будет смонтирован к кластеру:

Пример 2 - нет доступа к массиву

Значит тут мы полагаем, что администратор хранилищ уже настроил PE, и вам нужно только смонтировать том VVol:

Так как датастор VVol ранее не монтировался, нельзя просто создать array connection (нет доступа к массиву). В этом случае подойдет командлет Get-VasaStorageArray:

Передав в командлет монтирования массив FA-m50, имя кластера и имя датастора, можно смонтировать том VVol:

$vasaArrays = Get-VasaStorageArray
Mount-PfaVvolDatastore -vasaArray $vasaArrays[<desired index>] -cluster (get-cluster <cluster name>) -datastoreName <datastore name>

Если обобщить, то процесс монтирования датастора VVol с самого начала выглядит так:

• Установка модуля PowerShell
• Соединение с массивом
• Соединение с vCenter
• Создание хостовой группы (в случае с iSCSI нужно еще настроить iSCSI-таргеты)
• Зарегистрировать VASA-провайдер
• Смонтировать датастор VVol

Полный сценарий PowerShell приведен ниже:

install-module PureStorage.FlashArray.VMware

$flasharray = new-pfaConnection -endpoint flasharray-m50-1 -credentials (get-credential) -ignoreCertificateError -nonDefaultArray
connect-viserver -Server vcenter-02

$cluster = get-cluster Embarcadaro

New-PfaHostGroupfromVcCluster -cluster $cluster -iscsi -flasharray $flasharray

New-PfaVasaProvider -flasharray $flasharray -credentials (get-credential)

Mount-PfaVvolDatastore -flasharray $flasharray -cluster $cluster -datastoreName m50-VVolDS

А так в консоли vSphere Client:

Компания StarWind Software известна своим лидирующим в отрасли решением Virtual SAN, которое позволяет создать отказоустойчивый кластер хранилищ для виртуальных машин на различных платформах. Сегодня мы расскажем о средстве StarWind Virtual Tape Library (VTL), реализующем виртуальную ленточную библиотеку, и его совместном использовании с решением для резервного копирования и репликации Veeam Backup and Replication.

Это гостевой пост нашего спонсора - сервис-провайдера ИТ-ГРАД, предоставляющего услугу аренды виртуальных машин из облака. В MIT предложили систему, которая в два раза уменьшит объем электричества, потребляемого «твердотельниками» в ЦОД. Рассказываем, как она устроена.

Проблема энергопотребления

Приблизительно через десять лет на вычислительные системы (в целом) будет приходиться40% потребляемой электроэнергии. За пятую часть этого объема будут «ответственны» центры обработки данных.

Системы хранения данных — один из основных «потребителей» электроэнергии в ЦОД. Чтобы сократить расходы на содержание СХД, операторы дата-центров заменяют жесткие диски на твердотельные накопители. Последние более производительны и энергоэффективны: известны случаи, когда SSD уменьшали объем потребляемого стойками СХД электричества на 60%.

Но ситуация все равно далека от идеальной. В машинном зале крупного дата-центра могут находиться сотни стоек с накопителями, и счета за электроэнергию остаются большими. Поэтому сегодня разрабатываются новые технологии, чтобы еще сильнее сократить энергопотребление SSD. Одну из таких технологий представили в MIT. Специалисты вуза спроектировали архитектуру системы хранения данных на базе твердотельных накопителей, которая снижает расходы операторов ЦОД на электричество в два раза. Ее назвали LightStore.

Как устроена система

LightStore представляет собой хранилище типа «ключ — значение» (KV-хранилище). Ключом считаются пользовательские запросы к СХД, а значением — сами данные. Систему разворачивают на специальном аппаратном узле в сети ЦОД. Его подключают напрямую, в обход серверов хранения данных (дополнительно потребляющих электроэнергию).

Узел построен на базе энергоэффективного CPU, а также NAND- и DRAM-памяти. Управляет им контроллер и специализированное ПО. Первый компонент отвечает за обмен данными с массивами NAND, а второй — за хранение ключей и их обработку. В основе программной архитектуры LightStore лежат так называемые LSM-деревья — структуры данных, используемые во всех современных СУБД.

Кластер LightStore масштабируется линейно путем подключения дополнительных узлов к сети. Для этих целей применяются специальные адаптеры. Они формализуют пользовательские запросы к СХД и трансформируют их в понятные для нее команды. Обработка запросов производится с использованием согласованного хеширования — при добавлении новой пары ключ-значение, хеш рассчитывается только для нее, а не для всех пар. Аналогичный подход применяют системы Redis и Swift.

В общем случае архитектуру LightStore и схему ее подключений в ЦОД можно представить вот так:

По словам разработчиков, пропускная способность LightStore при работе в 10GbE-сети дата-центра превышает 600 Мбит/с. При этом один ее узел потребляет на 10 Вт меньше, чем узел «классических» SSD-систем — для них этот показатель равен 20 Вт. Также оборудование занимает в два раза меньше места, отчасти из-за того, что LightStore не требуются серверы хранения.

Сейчас инженеры из MIT занимаются исправлением недостатков LightStore и расширением функциональности системы. Например, ее «учат» работать с атомарными запросами и запросами по диапазону. Также в планах разработчиков добавить поддержку SQL-запросов. Авторы убеждены, что в будущем LightStore может стать отраслевым стандартом для SSD-хранилищ в центрах обработки данных.

Аналоги решения

В прошлом году компания Marvell, которая занимается разработкой СХД, анонсировала SSD-контроллеры с интеллектуальными функциями. Они построены на базе систем ИИ, которые оптимизируют энергопотребление SSD в ЦОД. Ожидается, что решение найдет применение в машинных залах организаций, занимающихся аналитикой больших данных.

Еще один пример — накопитель WD Blue SSD с повышенной производительностью и энергоэффективностью. Устройство использует спецификацию NVMe для подключения дисков к шине PCI Express. Такой подход позволил повысить эффективность накопителя при работе с большим числом параллельных запросов. Устройство имеет скорость чтения в 545 МБ/с и скорость записи в 525 МБ/с. NVMe может стать стандартом ИТ-индустрии для SSD-интерфейсов. Производителям аппаратного обеспечения больше не придется расходовать ресурсы на разработку уникальных драйверов и разъемов.

В будущем можно ожидать появления большего числа решений, повышающих энергоэффективность СХД, подобных системам из MIT, Marvell и WD.

Оригинал статьи в блоге ИТ-ГРАД.

Не так давно мы писали об обновлении платформы VMware Cloud Foundation 3.7, которая представляет собой набор продуктов для развертывания, исполнения, мониторинга и поддержки виртуальной инфраструктуры в онпремизном датацентре.

Архитектура VCF включает в себя компоненты VMware vRealize Suite, VMware vSphere Integrated Containers, VMware Integrated OpenStack, VMware Horizon, NSX и другие, работающие в онпремизной, облачной или гибридной инфраструктуре предприятия, которые желательно развертывать все вместе, но можно какие-то и опустить. Все это находится под управлением решения VMware SDDC Manager.

На днях был анонсирован еще один пакет решений - VMware Cloud Foundation Platinum. Смысл этой платформы - повышенная защищенность частных облаков, обеспечиваемая платформой виртуализации vSphere Platinum, где инфраструктура находится под наблюдением средства анализа и активной защиты - продукта AppDefense.

Он является ядром всей платформы с точки зрения безопасности и предоставляет множество возможностей, обеспечивающих защиту виртуальной инфраструктуры на различных уровнях:

Давайте посмотрим на ключевые моменты этой архитектуры:

1. Обеспечение умного подхода к безопасности.

По аналогии с vSphere Platinum и vCloud Suite Platinum, издание Platinum для VMware Cloud Foundation интегрирует решение AppDefense напрямую в гипервизор vSphere для защиты как самой платформы, так и рабочих нагрузок в виртуальных машинах. Фишка AppDefense - алгоритмы машинного обучения, которые позволяют обучиться нормальному сетевому поведению компонентов виртуального датацентра, а потом сигнализировать об отклонениях от этой модели и предпринимать некоторые шаги по активной защите инфраструктуры.

Действие AppDefense распространяется на vSphere, NSX и vSAN, что позволяет защитить все рабочие нагрузки, входящие в структуру Cloud Foundation.

2. Работа на различных уровнях в датацентре.

AppDefense не только смотрит на виртуальные машины извне, но и анализирует поведение приложений изнутри гостевых ОС, где их поведение полностью находится под наблюдением ML-алгоритмов. В этом процессе данные собираются от среды управления vCenter, а также различных средств разработки и фреймворков для управления виртуальной средой.

3. Многоуровневая защита.

AppDefense в рамках Cloud Foundation Platinum обеспечивает активную защиту на следующих уровнях:

• Compute - анализ поведения ВМ на вычислительном уровне, в том числе тех, кто имеет включенные функции шифрования (VM encryption), как при хранении, так и при перемещении машин между хранилищами.
• Network - решение NSX в виртуальном датацентре использует подход микросегментации и гранулярной безопасности, что полностью поддерживается рабочим процессом AppDefense (возможность перемещения политик безопасности вместе с ВМ, вне зависимости от топологии сети).
• Storage - поддержка шифрования vSAN (data-at-rest encryption) на уровне кластера, а также инфраструктуры KMIP (поддерживаются такие продукты, как CloudLink, Hytrust, SafeNet, Thales и Vormetric).
• Management - vCloud Suite автоматизирует рутинные операции (включая по обеспечению безопасности и мониторингу среды в реальном времени), исключая вероятность возникновения ошибок и уязвимостей по причине человеческого фактора.

Cloud Foundation Platinum - это законченное решение для гибридных виртуальных сред (частное+публичное облако под управлением одного пакета решений), где поведение всех приложений находится под наблюдением AppDefense в рамках комплексного рабочего процесса по обеспечению безопасности. Каждая из задач может выполняться пользователем с соответствующей ролью в виртуальном датацентре:

Более подробно о VMware Cloud Foundation Platinum можно узнать по этой ссылке.

Дункан написал полезный пост о том, влияет ли установка лимитов по вводу-выводу в кластере VMware vSAN (I/O Limit) на производительность операций ресинхронизации кластера и перемещение машин между хранилищами Storage vMotion (SVMotion).

Вопрос этот важен, так как многие пользуются лимитами для виртуальных машин на уровне хранилищ vSAN, но не хотят, чтобы в случае сбоя ресинхронизация кластера или перемещение машин происходили с ограничениями, которые могут увеличить время восстановления в разы.

Ответ тут прост - нет, не влияет. Лимиты устанавливаются на уровне гостевой системы для VMDK-дисков виртуальных машин и сопутствующих объектов (например, снапшоты, своп и т.п.), поэтому операции, которые проводятся извне со стороны платформы, в этом не участвуют.

Таким образом, лимиты для виртуальных машин можно ставить без ограничений и не заботиться о том, что это повлияет на время восстановление кластера и отдельных ВМ в случае сбоя. Операции SVMotion также затронуты не будут.

Июнь оказался весьма богат на новые релизы на сайте проекта VMware Labs - недавно мы писали про обновление Horizon DaaS Migration Tool 2.1 для миграции облака DaaS, новое средство Flowgate для агрегации метрик, обновления HCIBench и USB Network Native Driver for ESXi.

Но на этом релизы не остановились - на днях VMware выпустила обновленную утилиту IOBlazer, которая позволяет сгенерировать нагрузку на хранилища с любых платформ - Linux, Windows и OSX. Утилита была выпущена еще в 2011 году, но с тех пор не дорабатывалась, а вот на днях мы увидели ее версию 1.01.

Основная фича утилиты - возможность тонко кастомизировать параметры нагрузки на хранилище изнутри виртуальной машины, такие как размер IO и паттерн нагрузки, пакетирование (объем исходящих операций ввода-вывода), временные промежутки между пакетами, микс трафика чтения/записи, буфферизованные или прямые операции ввода-вывода и многое другое.

IOBlazer также может "проигрывать" записанные логи VSCSI, которые были получены за счет использования утилиты vscsiStats. В качестве метрик производительности можно получить пропускную способность в IOPS и в мегабайтах в секунду, а также задержки ввода-вывода (IO latency). Это дает возможность IOBlazer сгенерировать синтетическую нагрузку на диск виртуальной машины, которая соответствует реальной нагрузке, с возможностью ее повторения в любой момент.

IOBlazer вырос из минималистичного эмулятора MS SQL Server, который бы сфокусирован на эмуляции только нагрузки по вводу-выводу. Ранее утилита имела очень ограниченные возможности по генерации нагрузки по модели MS SQL Server IO (Асинхронность, небуфферизованные IO, параметры Gather/Scatter), теперь же все стало существенно лучше. Но 2 ограничения все еще остаются:

1. Выравнивание доступа к памяти по 4 КБ (страница памяти).

2. Выравнивание операций доступа к диску по 512 байт (дисовый сектор).

Утилиту не надо устанавливать - она запускается из дистрибутива. Инструкции можно найти в файле README. Скачать IOBlazer 1.01 можно по этой ссылке. В комплекте также идет исходник на C, который вы можете собрать самостоятельно.

Довольно давно VMware не обновляла свой универсальный фреймворк для управления виртуальной инфраструктурой, но вот на днях вышел VMware PowerCLI 11.3. Напомним, что прошлая версия пакета VMware PowerCLI 11.2 вышла в марте этого года.

Давайте посмотрим, что нового появилось в PowerCLI 11.3:

1. Добавлено 22 новых командлета для управления компонентами HCX и SPBM (политики хранилищ).

Их поддержка уже была в версии 11.2, но теперь она расширилась. Для HCX теперь доступны следующие командлеты:

• Get/New/Remove/Set-HCXComputeProfile
• Get-HCXInventoryCompute
• Get-HCXInventoryDatastore
• Get-HCXInventoryDVS
• Get-HCXInventoryNetwork
• Get-HCXNetworkBacking
• Get/New/Remove/Set-HCXNetworkProfile
• Get/New/Remove/Set-HCXServiceMesh
• Get-HCXStorageProfile
• New-HCXComputeProfileDVS
• New-HCXComputeProfileNetwork
• New-HCXServiceMeshDVS

В плане поддержки SPBM, появился новый командлет Get-SpbmView, который предоставляет прямой доступ к API механизма управления политиками хранилищ. В примере ниже выведен список доступных сервисов и взаимодействие с сервисом Replication Manager для получения набора доступных методов:

Также теперь командлеты Get/Set-SpbmEntityConfiguration могут просматривать или изменять политики хранилищ SPBM для датасторов. Вот пример работ командлета для вывода параметров политики датастора:

2. Поддержка vSphere 6.7 Update 2 в модуле VMware.VIM.

Теперь последняя версия платформы vSphere полностью поддерживается для управления через этот модуль.

3. Поддержка opaque networks в командлете Get-VirtualNetwork.

Эти сети появляются как результат работы с логическими коммутаторами в решении NSX-T. В версии PowerCLI 11.2 управление такими сетями было доступно только через прямой API, а сейчас можно управлять ими с помощью высокоуровневого командлета:

Для получения дополнительной информации о таких сетях обратитесь к статье Configuring VMs with Opaque Networks.

4. Добавлена возможность создания дополнительных типов сетевых адаптеров.

Здесь были добавлены адаптеры SriovEthernetCard и Vmxnet3Vrdma, а также появились параметры PhysicalFunction и DeviceProtocol.

5. Поддержка высокоуровнего преобразования мгновенных клонов (instant clones) в обычные ВМ.

Начиная с vSphere 6.7, мгновенные клоны (instant clones) стали доступны для пользователей в производственной среде, но управлять ими можно было только через API. Теперь же с помощью PowerCLI 11.3 можно использовать командлет Set-VM совместно с параметром PromoteDisks, что даст возможность преобразовать машину instant clone в самостоятельную ВМ, которая больше не зависит от родительской. 

6. Обновлена обработка статусов кластера для свойства SpbmEnabled.

Теперь для датастора в кластере не показывается статус SpbmEnabled, так как он всегда включен и не может быть отключен пользователем.

7. Обновленная обработка пакетного режима привязки тэгов.

Теперь привязка тэгов vSphere tags с помощью командлета New-TagAssignment идет на стороне сервера в пакетном режиме, что дает существенный прирост производительности (от 12 до 18 раз):

О производительности этого процесса есть также интересная статья "Writing Performant Tagging Code".

Для получения более полной информации о нововведениях обратитесь к документу VMware PowerCLI Change Log. О самих возможностях фреймворка прекрасно рассказано в документе VMware PowerCLI 11.3.0 User’s Guide. Ну а о том, как работает тот или иной командлет, можно узнать в VMware PowerCLI 11.3.0 Cmdlet Reference.

Как обычно, обновление на версию PowerCLI 11.3 надо делать помощью командлета Update-Module:

На сайте VMware Labs обновилась утилита HCIBench до версии 2.1.

Напомним, что о версии HCIBench 2.0 мы писали вот тут, а здесь мы рассматривали использование этой утилиты для замеров производительности кластеров VMware vSAN. Напомним, что это средство позволяет провести комплексный тест производительности отказоустойчивых кластеров хранилищ Virtual SAN, а также других конфигураций виртуальной инфраструктуры.

Проект HCIbecnh ("Hyper-converged Infrastructure Benchmark") является оберткой для известного open source теста VDbench, он позволяет организовать автоматизированное тестирование гиперконвергентного кластера (HCI-кластера). Гиперконвергентный кластер - это когда все его вычислительные ресурсы, системы хранения и сети виртуализованы и собраны в единую интегрированную сущность и управляются из одной точки.

Целью такого тестирования может быть, например, необходимость убедиться, что развернутая инфраструктура обеспечивает достаточную производительность для планируемой на нее нагрузки.

Что нового появилось в HCIBench 2.1:

• Интерфейс переключили на темную тему.
• Переработанная технология подготовки VMDK, которая теперь работает гораздо быстрее за счет использования рандомизации на дедуплицированных хранилищах.
• Добавлена возможность обновления процесса подготовки VMDK.
• Добавлена проверка портов базы данных Graphite в процесс превалидации.
• Пароли vCenter и хостов ESXi затемняются при сохранении
• Добавлена кнопка удаления гостевой ВМ ("Delete Guest VM").
• Пофикшены проблемы с дисплеями для Grafana.
• Пофикшена проблема с пустыми результатами при отработки модели нагрузки FIO (Flexible I/O).
• Множество мелких исправлений ошибок.

Скачать HCIBench 2.1 можно по этой ссылке. Документация пока доступна только для версии 2.0.

Администраторы отказоустойчивых кластеров хранилищ VMware vSAN часто сталкиваются с проблемами производительности, наблюдаемыми в виртуальной среде. Как правило, о таких проблемах администратор узнает двумя путями: либо ему сообщают пользователи, либо он видит алерты, которые генерируются в консоли клиента vSphere Client при превышении определенных пороговых значений.

Так или иначе, администратор должен, прежде всего, выяснить, что проблема низкой производительности приложений проявляет себя именно на уровне гостевой системы. В этом случае VMware предлагает придерживаться следующего рабочего процесса:

Основные моменты траблшутинга по такому воркфлоу рассказаны в документе "Troubleshooting vSAN Performance". Самый очевидный симптом проблем - это задержки (Latency) на уровне гостевой ОС (то есть время, затраченное на выполнение транзакции ввода-вывода), которые приводят к медленной работе приложений.

Задержки измеряются в миллисекундах, и интерпретация их значений зависит от контекста - размер блока ввода-вывода, характер потока (чтение/запись, последовательное/случайное). При этом latency измеряется на некотором сегменте прохождения команд к хранилищу, на каждом из участков которого также возникают свои составляющие задержек. Анализ таких компонентов Storage stack в контексте задержек и поиск узких мест - и есть основная задача администратора, решающего проблемы низкой производительности приложений для пользователей. Многое из этого можно делать с помощью утилиты ESXTOP, о которой мы много писали.

Обратите внимание, что на иллюстрации фреймворка выше, анализ виртуальной инфраструктуры и анализ приложений и их рабочих процессов находится еще до анализа метрик. Это связано с тем, что выбор метрик, на которые стоит обратить внимание в среде VMware vSAN, зависит от характера происходящих проблем.

После того, как администратор выяснил основные признаки проблемы и локализовал ее на уровне приложений, можно приступать к анализу метрик. Алгоритм действий приведен в документе "Troubleshooting vSAN Performance":

Тут рекомендуется делать следующее:

• Шаг 1 - просматриваем метрики в гостевой ОС проблемной ВМ, чтобы убедиться, что проблемы с производительностью хранилища ощущаются на уровне приложений.
• Шаг 2 - просматриваем метрики на уровне кластера vSAN, чтобы в целом понять масштаб проблемы - нет ли других аномалий в кластере. Это позволяет идентифицировать потенциальные "наводки" от других компонентов виртуальной инфраструктуры.
• Шаг 3 - просматриваем метрики на уровне хоста ESXi, чтобы соотнести метрики внутри гостевой ОС и всего хоста в целом с точки зрения latency.
• Шаг 4 - смотрим на хосте метрики дисковой группы, чтобы найти источник повышенной latency.
• Шаг 5 - если не нашли проблему на шаге 4, то смотрим на сеть хоста и метрики VMkernel, чтобы убедиться, что сеть функционирует штатно.

То есть смысл прост - если что-то тормозит в кластере VMware vSAN, то это либо дисковая подсистема, либо сетевая инфраструктура. Ну и главное - правильно идентифицировать хост/хосты ESXi, где находятся компоненты виртуальной машины.

И еще одна важная рекомендация - при траблшутинге старайтесь не менять несколько настроек одновременно, чтобы решить проблему. Во-первых, вы не сможете понять, какая из настроек или их комбинация дала правильный эффект, а, во-вторых, вы не сразу можете обнаружить, что сделанные вами настройки может и помогли машине работать быстрее, но остальные машины этого хоста или кластера значительно просели по производительности. А вернуть все назад может быть не так уж и просто.